The
objective of Windows Azure is to automate the service life cycle as
much as possible. Windows Azure service life cycle has five distinct
phases and four different roles.
The five phases are as follows:
Design and development:
In this phase, the on-premise team plans, designs, and develops a cloud
service for Windows Azure. The design includes quality attribute
requirements for the service and the solution to fulfill them. This
phase is conducted completely on-premise, unless there is some proof of
concept (POC) involved. The key roles involved in this phase are
on-premise stakeholders. For the sake of simplicity, I have combined
these on-site design roles into a developer role.
Testing:
In this phase, the quality attributes of the cloud service are tested.
This phase involves on-premise as well as Windows Azure cloud testing.
The tester role is in charge of this phase and tests end-to-end quality
attributes of the service deployed into cloud testing or staging
environment.
Provisioning:
Once the application is tested, it can be provisioned to Windows Azure
cloud. The deployer role deploys the cloud service to the Windows Azure
cloud. The deployer is in charge of service configurations and makes
sure the service definition of the cloud service is achievable through
production deployment in Windows Azure cloud. The configuration
settings are defined by the developer, but the production values are
set by the deployer. In this phase, the role responsibilities
transition from on-premise to the Windows Azure cloud. The fabric
controller in Windows Azure assigns the allocated resources as per the
service model defined in the service definition. The load balancers and
virtual IP address are reserved for the service.
Deployment:
In the deployment phase, the fabric controller commissions the
allocated hardware nodes into the end state and deploys services on
these nodes as defined in the service model and configuration. The
fabric controller also has the capability of upgrading a service in
running state without disruptions. The fabric controller abstracts the
underlying hardware commissioning and deployment from the services. The
hardware commissioning includes commissioning the hardware nodes,
deploying operating system images on these nodes, and configuring
switches, access routers, and load-balancers for the externally facing
roles (e.g., Web role).
Maintenance:
Windows Azure is designed with the assumption that failure will occur
in hardware and software. Any service on a failed node is redeployed
automatically and transparently, and the fabric controller
automatically restarts any failed service roles. The fabric controller
allocates new hardware in the event of a hardware failure. Thus, fabric
controller always maintains the desired number of roles irrespective of
any service, hardware or operating system failures. The fabric
controller also provides a range of dynamic management capabilities
like adding capacity, reducing capacity and service upgrades without
any service disruptions. Figure 2 illustrates the fabric controller architecture.
In Figure 2,
the fabric controller abstracts the underlying Windows Server 2008
operating system and the hardware from the service role instances, and
it performs the following high-level tasks:
Allocates the nodes
Starts operating system images on the nodes
Configures the settings as per the service model described by the service creator
Starts the service roles on allocated nodes
Configures load balancers, access routers, and switches
Maintains the desired number of role instances of the service irrespective of any service, hardware or operating system failures
Table 1 lists the quality attribute requirements for Windows Azure and the description of how it satisfies those.
Table 1. Quality Attributes
| Quality Attribute | Description |
|---|
| High availability | Windows
Azure provides built-in redundancy with access routers, load balancers,
and switches. Load balancers are automatically provisioned for external
facing roles (e.g. Web roles). |
| Service isolation | Every
service operates within the parameters of its service model. Services
can access only the resources declared in the service model
configuration. These resources include endpoints, local storage, and
local machine resources. |
| Security | Every
service role instance runs in the Windows user context. The instance
does not have access to any administrative privileges and limited
native execution access when native access is enabled. |
| Automatic provisioning | The
fabric controller automates the service deployment from bare-metal
hardware to service role deployment. The service model and the
configuration information act as the instruction set for the fabric
controller to provision appropriate hardware and virtual machine
instances. The fabric controller can also upgrade your service while
running without disruptions. |
